Apparatus, system and method for member matching

ABSTRACT

An apparatus, system, and method for member matching. In one embodiment, the apparatus includes an input adapter, a processor, and an output adapter. The input adapter may receive a first data record from a plurality of data records stored in one or more databases. The processor may generate a first data key from one or more field values in the first data record, compare a second data key associated with a second data record with the first data key associated with the first data record, and identify a match between the first data key and the second data key. In one embodiment, the output adapter may produce an output configured to identify the first data record and the second data record in response to identification of the match.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to U.S. Application No. 61/121,027filed on Dec. 9, 2008, the entire disclosure of which is specificallyincorporated herein by reference in its entirety without disclaimer.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates to data management and more particularly relatesto an apparatus, a system and a method for member matching.

2. Description of the Related Art

Evaluation of health care claims data at the member level is hindered bylack of access to complete information for members who move from oneplan to another. This is especially problematic when the analysis isdone for an individual health plan and only data from that plan isavailable for use. It is complicated by the fact that patients aremobile, visit multiple providers and enroll in multiple plans. Thechallenge is to uniquely identify members across the health plans andcreate non-duplicative eligibility records. This requires matchingmembers or data records across health plans.

Typical record matching solutions require the use of a social securitynumber or other unique identifiers that are common among the severaldatasets. Unfortunately, most healthcare plans and other data providers,such as financial institutions, are unwilling or unable to supply socialsecurity numbers or other unique identifiers because of privacyconcerns.

The referenced shortcomings are not intended to be exhaustive, butrather are among many that tend to impair the effectiveness ofpreviously known techniques for member matching; however, thosementioned here are sufficient to demonstrate that the methodologiesappearing in the art have not been satisfactory and that a significantneed exists for the techniques described and claimed in this disclosure.

SUMMARY OF THE INVENTION

From the foregoing discussion, it should be apparent that a need existsfor an apparatus, system, and method for member matching.

An apparatus for member matching is presented. In one embodiment, theapparatus includes an input adapter, a processor, and an output adapter.The input adapter may receive a first data record from a plurality ofdata records stored in one or more databases. The processor may generatea first data key from one or more field values in the first data record,compare a second data key associated with a second data record with thefirst data key associated with the first data record, and identify amatch between the first data key and the second data key. In oneembodiment, the processor may assign a common identifier to the firstdata record and the second data record in response to the match betweenthe first key and the second key, the common identifier associating thefirst data record and the second data record with a unique entity. Inone embodiment, the output adapter may produce an output configured toidentify the first data record and the second data record in response toidentification of the match.

In a further embodiment, the processor may clean the first data recordand the second data record before comparing the first data key and thesecond data key. In still a further embodiment, the processor maystandardize the first and second data record before comparing the firstdata key and the second data key. Additionally, the processor maygenerate a plurality of first data keys and second data keys accordingto a plurality of predetermined combinations of field values. In afurther embodiment, comparing the first data key and the second data keyincludes comparing the plurality of first data keys with the pluralityof second data keys.

A system is also presented for member matching. In one embodiment, thesystem may include one or more data storage devices configured to storea plurality of data records. The system may also include a serverconfigured to receive a first data record from the plurality of datarecords stored in one or more databases located on the one or more datastorage devices, generate a first data key from one or more field valuesin the first data record, compare a second data key associated with asecond data record with the first data key associated with the firstdata record, identify a match between the first data key and the seconddata key, and produce an output configured to identify the first datarecord and the second data record in response to identification of thematch.

A tangible computer program product comprising a computer readablemedium having computer usable program code executable to performoperations for member matching is also presented. In one embodiment, theoperations include receiving a first data record from a plurality ofdata records stored in one or more databases, generating a first datakey from one or more field values in the first data record, comparing asecond data key associated with a second data record with the first datakey associated with the first data record, identifying a match betweenthe first data key and the second data key, and producing an outputconfigured to identify the first data record and the second data recordin response to identification of the match.

A method is also presented for member matching. The method in thedisclosed embodiments substantially includes the steps necessary tocarry out the functions presented above with respect to the operation ofthe described apparatus and system. In one embodiment, the methodincludes receiving a first data record from a plurality of data recordsstored in one or more databases, generating a first data key from one ormore field values in the first data record, comparing a second data keyassociated with a second data record with the first data key associatedwith the first data record, identifying a match between the first datakey and the second data key, and producing an output configured toidentify the first data record and the second data record in response toidentification of the match.

The term “coupled” is defined as connected, although not necessarilydirectly, and not necessarily mechanically.

The terms “a” and “an” are defined as one or more unless this disclosureexplicitly requires otherwise.

The term “substantially” and its variations are defined as being largelybut not necessarily wholly what is specified as understood by one ofordinary skill in the art, and in one non-limiting embodiment“substantially” refers to ranges within 10%, preferably within 5%, morepreferably within 1%, and most preferably within 0.5% of what isspecified.

The terms “comprise” (and any form of comprise, such as “comprises” and“comprising”), “have” (and any form of have, such as “has” and“having”), “include” (and any form of include, such as “includes” and“including”) and “contain” (and any form of contain, such as “contains”and “containing”) are open-ended linking verbs. As a result, a method ordevice that “comprises,” “has,” “includes” or “contains” one or moresteps or elements possesses those one or more steps or elements, but isnot limited to possessing only those one or more elements. Likewise, astep of a method or an element of a device that “comprises,” “has,”“includes” or “contains” one or more features possesses those one ormore features, but is not limited to possessing only those one or morefeatures. Furthermore, a device or structure that is configured in acertain way is configured in at least that way, but may also beconfigured in ways that are not listed.

Other features and associated advantages will become apparent withreference to the following detailed description of specific embodimentsin connection with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The following drawings form part of the present specification and areincluded to further demonstrate certain aspects of the presentinvention. The invention may be better understood by reference to one ormore of these drawings in combination with the detailed description ofspecific embodiments presented herein.

FIG. 1 is a schematic block diagram illustrating one embodiment of asystem for member matching;

FIG. 2 is a schematic block diagram illustrating one embodiment of adatabase system for storing data records;

FIG. 3 is a schematic block diagram illustrating one embodiment of acomputer system that may be used in accordance with certain embodimentsof the system for member matching;

FIG. 4 is a schematic logical diagram illustrating the various layers ofoperation in a system for member matching;

FIG. 5 is a schematic block diagram illustrating one embodiment of anapparatus for member matching;

FIG. 6 is a detailed schematic block diagram illustrating one embodimentof an apparatus for member matching;

FIG. 7 is a schematic flowchart diagram illustrating one embodiment of amethod for member matching;

FIG. 8 is a high-level schematic flowchart diagram illustrating oneembodiment of a process for member matching;

FIG. 9 is a schematic flowchart diagram illustrating one embodiment of asub-process for member matching (mem_match routine);

FIG. 10 is a schematic flowchart diagram illustrating one embodiment ofa sub-process for preparing the data, performing a preliminary match(intra-plan) search based on member identifiers and performing matchesacross data sources; and

FIGS. 11A-11B are schematic flowchart diagrams illustrating asub-process for member matching.

DETAILED DESCRIPTION

The invention and the various features and advantageous details areexplained more fully with reference to the nonlimiting embodiments thatare illustrated in the accompanying drawings and detailed in thefollowing description. Descriptions of well known starting materials,processing techniques, components, and equipment are omitted so as notto unnecessarily obscure the invention in detail. It should beunderstood, however, that the detailed description and the specificexamples, while indicating embodiments of the invention, are given byway of illustration only and not by way of limitation. Varioussubstitutions, modifications, additions, and/or rearrangements withinthe spirit and/or scope of the underlying inventive concept will becomeapparent to those skilled in the art from this disclosure.

Many of the functional units described in this specification have beenlabeled as modules, in order to more particularly emphasize theirimplementation independence. For example, a module may be implemented asa hardware circuit comprising custom VLSI circuits or gate arrays,off-the-shelf semiconductors such as logic chips, transistors, or otherdiscrete components. A module may also be implemented in programmablehardware devices such as field programmable gate arrays, programmablearray logic, programmable logic devices or the like.

Modules may also be implemented in software for execution by varioustypes of processors. An identified module of executable code may, forinstance, comprise one or more physical or logical blocks of computerinstructions which may, for instance, be organized as an object, aprocedure, or a function. Nevertheless, the executables of an identifiedmodule need not be physically located together, but may comprisedisparate instructions stored in different locations which, when joinedlogically together, comprise the module and achieve the stated purposefor the module.

Indeed, a module of executable code may be a single instruction, or manyinstructions, and may even be distributed over several different codesegments, among different programs, and across several memory devices.Similarly, operational data may be identified and illustrated hereinwithin modules, and may be embodied in any suitable form and organizedwithin any suitable type of data structure. The operational data may becollected as a single data set, or may be distributed over differentlocations including over different storage devices.

Reference throughout this specification to “one embodiment,” “anembodiment,” or similar language means that a particular feature,structure, or characteristic described in connection with the embodimentis included in at least one embodiment of the present invention. Thus,appearances of the phrases “in one embodiment,” “in an embodiment,” andsimilar language throughout this specification may, but do notnecessarily, all refer to the same embodiment.

Furthermore, the described features, structures, or characteristics ofthe invention may be combined in any suitable manner in one or moreembodiments. In the following description, numerous specific details areprovided, such as examples of programming, software modules, userselections, network transactions, database queries, database structures,hardware modules, hardware circuits, hardware chips, etc., to provide athorough understanding of embodiments of the invention. One skilled inthe relevant art will recognize, however, that the invention may bepracticed without one or more of the specific details, or with othermethods, components, materials, and so forth. In other instances,well-known structures, materials, or operations are not shown ordescribed in detail to avoid obscuring aspects of the invention.

FIG. 1 illustrates one embodiment of a system 100 for member matching.The system 100 may include a server 102, a data storage device 104, anetwork 108, and a user interface device 110. In a further embodiment,the system 100 may include a storage controller 106 or storage serverconfigured to manage data communications between the data storage device104 and the server 102 or other components in communication with thenetwork 108. In an alternative embodiment, the storage controller 106may be coupled to the network 108. In a general embodiment, the system100 may compare records from one or more databases and match groups ofrecords based on a common attribute. Specifically, the system 100 maycompare healthcare records from a plurality of databases to identify agroup of records associated with an individual or member of a healthcareplan.

In one embodiment, the user interface device 110 is referred to broadlyand is intended to encompass a suitable processor-based device such as adesktop computer, a laptop computer, a Personal Digital Assistant (PDA),a mobile communication device or organizer device having access to thenetwork 108. In a further embodiment, the user interface device 110 mayaccess the Internet to access a web application or web service hosted bythe server 102 and provide a user interface for enabling the serviceconsumer (user) to enter or receive information. The user may also inputa selection of field values to be used to generate the first data key,and other user inputs and controls.

The network 108 may facilitate communications of data between the server102 and the user interface device 110. The network 108 may include anytype of communications network including, but not limited to, a directPC to PC connection, a local area network (LAN), a wide area network(WAN), a modem to modem connection, the Internet, a combination of theabove, or any other communications network now known or later developedwithin the networking arts which permits two or more computers tocommunicate, one with another. In a further embodiment of the system100, the user interface device 110 and/or the network 108 may beomitted.

In one embodiment, the server 102 is configured to select a first datarecord from a plurality of data records stored in one or more databases,generate a first data key from one or more field values in the firstdata record, compare a second data key associated with a second datarecord with the first data key associated with the first data record,identify a match between the first data key and the second data key, andproduce an output configured to identify the first data record and thesecond data record in response to identification of the match.Additionally, the server may access data stored in the data storagedevice 104 via a Storage Area Network (SAN) connection, a LAN, a databus, or the like.

The data storage device 104 may include a hard disk, including harddisks arranged in a Redundant Array of Independent Disks (RAID) array, atape storage drive comprising a magnetic tape data storage device, anoptical storage device, or the like. In one embodiment, the data storagedevice 104 may store health related data, such as insurance claims data,consumer data, or the like. The data may be arranged in a database andaccessible through Structured Query Language (SQL) queries, or otherdata base query languages or operations.

FIG. 2 illustrates one embodiment of a data management system 200configured to store and manage data for member matching. In oneembodiment, the system 200 may include a server 102. The server 102 maybe coupled to a data-bus 202. In one embodiment, the system 200 may alsoinclude a first data storage device 204, a second data storage device206 and/or a third data storage device 208. In further embodiments, thesystem 200 may include additional data storage devices (not shown). Insuch an embodiment, each data storage device 204-208 may host a separatedatabase of data records. The data records may include healthcareinsurance claims data, consumer data, socioeconomic data, financialdata, or the like. In a particular embodiment, the data records mayinclude insurance claims data related to individuals from multiplesources, including pharmacies, hospitals, clinics, doctor's offices,urgent care centers, or the like. In a further embodiment, the datarecords may include insurance claims information from multiple insuranceorganizations, including Medicare, Medicaid, secondary insurers, or avariety of private insurers. The customer information in each databasemay be keyed to a common field or identifier, such as an individual'sname, social security number, customer number, or the like.Alternatively, the storage devices 204-208 may be arranged in a RAIDconfiguration for storing redundant copies of the database or databasesthrough either synchronous or asynchronous redundancy updates.

In one embodiment, the server 102 may perform the methods describedherein on selected data storage devices 204-206 to collect aconsolidated set of data elements associated with an individual or groupof individuals. The server 102 may store the consolidated data set in aconsolidated data storage device 208. In such an embodiment, the server102 may refer back to the consolidated data storage device 208 to obtaina set of data elements associated with a specified individual. Inanother alternative embodiment, multiple databases may be stored on asingle consolidated data storage device 208.

In various embodiments, the server 102 may communicate with the datastorage devices 204-208 over the data-bus 202. The data-bus 202 maycomprise a SAN, a LAN, or the like. The communication infrastructure mayinclude Ethernet, Fibre-Chanel Arbitrated Loop (FC-AL), Small ComputerSystem Interface (SCSI), and/or other similar data communication schemesassociated with data storage and communication. For example, thereserver 102 may communicate indirectly with the data storage devices204-208; the server first communicating with a storage server or storagecontroller 106.

In one example of the system 200, the first data storage device 204 maystore data associated with a first private insurer, including insuranceclaims made by one or more individuals. The insurance claims data mayinclude data associated with medical services, procedures, andprescriptions utilized by the individual. In one embodiment, the seconddata storage device 206 may store insurance claims data from a state orfederal government health insurance program, such as Medicare orMedicaid. The third data storage device 208 may store health insuranceinformation from a secondary insurer. For example, the third datastorage device 208 may include data associated with supplementalpharmacy claims, dental insurance, vision insurance, or the like.

The server 102 may host a software application configured for membermatching. The software application may further include modules orfunctions for interfacing with the data storage devices 204-208,interfacing a network 108, interfacing with a user, and the like. In afurther embodiment, the server 102 may host an engine, applicationplug-in, or application programming interface (API). In anotherembodiment, the server 102 may host a web service or web accessiblesoftware application.

In a specific embodiment, a data record may include one or more datafields. For example, the data record may include data fields associatedwith an individual's first, middle, and last names. The data record mayalso include a data field associated with a date of birth and/or genderof the individual. The data fields may also include fields for contactinformation, including address, city, state, zip code, telephone number,and the like. The data fields may also include the individual's coverageeffective and end dates. The data fields may also include a date and/ordescription of a service provided, and a designation of the health planto which the claim was made.

FIG. 3 illustrates a computer system 300 adapted according to certainembodiments of the server 102 and/or the user interface device 110. Thecentral processing unit (CPU) 302 is coupled to the system bus 304. TheCPU 302 may be a general purpose CPU or microprocessor. The presentembodiments are not restricted by the architecture of the CPU 302, solong as the CPU 302 supports the modules and operations as describedherein. The CPU 302 may execute the various logical instructionsaccording to the present embodiments. For example, the CPU 302 mayexecute machine-level instructions according to the exemplary operationsdescribed below with reference to FIGS. 7-11.

The computer system 300 also may include Random Access Memory (RAM) 308,which may be SRAM, DRAM, SDRAM, or the like. The computer system 300 mayutilize RAM 308 to store the various data structures used by a softwareapplication configured to member matching. The computer system 300 mayalso include Read Only Memory (ROM) 306 which may be PROM, EPROM,EEPROM, or the like. The ROM may store configuration information forbooting the computer system 300. The RAM 308 and the ROM 306 hold userand system 100 data.

The computer system 300 may also include an input/output (I/O) adapter310, a communications adapter 314, a user interface adapter 316, and adisplay adapter 322. The I/O adapter 310 and/or user the interfaceadapter 316 may, in certain embodiments, enable a user to interact withthe computer system 300 in order to input information for authenticatinga user, identifying an individual, or receiving health profileinformation. In a further embodiment, the display adapter 322 maydisplay a graphical user interface associated with a software orweb-based application for member matching.

The I/O adapter 310 may connect to one or more storage devices 312, suchas one or more of a hard drive, a Compact Disk (CD) drive, a floppy diskdrive, a tape drive, to the computer system 300. The communicationsadapter 314 may be adapted to couple the computer system 300 to thenetwork 106, which may be one or more of a LAN and/or WAN, and/or theInternet. The user interface adapter 316 couples user input devices,such as a keyboard 320 and a pointing device 318, to the computer system300. The display adapter 322 may be driven by the CPU 302 to control thedisplay on the display device 324.

The present embodiments are not limited to the architecture of system300. Rather the computer system 300 is provided as an example of onetype of computing device that may be adapted to perform the functions ofserver 102 and/or the user interface device 110. For example, anysuitable processor-based device may be utilized including withoutlimitation, including personal data assistants (PDAs), computer gameconsoles, and multi-processor servers. Moreover, the present embodimentsmay be implemented on application specific integrated circuits (ASIC) orvery large scale integrated (VLSI) circuits. In fact, persons ofordinary skill in the art may utilize any number of suitable structurescapable of executing logical operations according to the describedembodiments.

FIG. 4 illustrates one embodiment of a network-based system 400 formember matching. In one embodiment, the network-based system 400includes a server 102. Additionally, the network-based system 400 mayinclude a user interface device 110. In still a further embodiment, thenetwork-based system 400 may include one or more network-based clientapplications 402 configured to be operated over a network 108 includingan intranet, the Internet, or the like. In still another embodiment, thenetwork-based system 400 may include one or more data storage devices104.

The network-based system 400 may include components or devicesconfigured to operate in various network layers. For example, the server102 may include modules configured to work within an application layer404, a presentation layer 406, a data access layer 408 and a metadatalayer 410. In a further embodiment, the server 102 may access one ormore data sets 420-424 that comprises a data layer or data tier 412. Forexample, a first data set 418 a second data set 420 and a third data set422 may comprise data tier 412 that is stored on one or more datastorage devices 204-206.

One or more web applications 412 may operate in the application layer404. For example, a user may interact with the web application 412though one or more I/O interfaces 318, 320 configured to interface withthe web application 412 through an I/O adapter 310 that operates on theapplication layer. In one particular embodiment, a web application 412may be provided for member matching that includes software modulesconfigured to perform the steps of selecting a first data record from aplurality of data records stored in one or more databases, generating afirst data key from one or more field values in the first data record,comparing a second data key associated with a second data record withthe first data key associated with the first data record, identifying amatch between the first data key and the second data key, and producingan output configured to identify the first data record and the seconddata record in response to identification of the match.

In a further embodiment, the server 102 may include components, devices,hardware modules, or software modules configured to operate in thepresentation layer 406 to support one or more web services 414. Forexample, a web application 412 may access a web service 414 to performone or more web-based functions for the web application 412. In oneembodiment, a web application 412 may operate on a first server 102 andaccess one or more web services 414 hosted on a second server (notshown) during operation.

For example, a web application 412 for matching diverse recordsassociated with a common individual, or other information may access afirst web service 414 for cleaning the first data record and the seconddata record before comparing the first data key and the second data keyand a second web service 414 for standardizing the first and second datarecords before comparing the first data key and the second data key. Theweb services 414 may receive the first data record and the second datarecord from the data storage device 104. In response, the web service414 may return data cleaned and/or standardized data records. One ofordinary skill in the art will recognize various web-based architecturesemploying web services 414 for modular operation of a web application412.

In one embodiment, a web application 412 or a web service 414 may accessone or more of the data sets 420-424 through the data access layer 408.In certain embodiments, the data access layer 408 may be divided intoone or more independent data access layers 416 for accessing individualdata sets 420-424 in the data tier 412. These individual data accesslayers 416 may be referred to as data sockets or adapters. The dataaccess layers 416 may utilize metadata from the metadata layer 410 toprovide the web application 412 or the web service 414 with specificaccess to the data tier 418.

For example, the data access layer 416 may include operations forperforming a query of the data sets 420-424 to retrieve specificinformation for the web application 412 or the web service 414. In amore specific example, the data access layer 416 may include a query fora preselected group of records or all records stored in the data sets420-424.

FIG. 5 illustrates one embodiment of an apparatus 500 for membermatching. In one embodiment, the apparatus 500 is a server 102configured to load and operate software modules 502-506 configured formember matching. Alternatively, the apparatus 500 may include hardwaremodules 502-506 configured with analogue or digital logic, firmwareexecuting FPGAs, or the like configured to receive a first data recordfrom the plurality of data records stored in one or more databaseslocated on the one or more data storage devices, generate a first datakey from one or more field values in the first data record, compare asecond data key associated with a second data record with the first datakey associated with the first data record, identify a match between thefirst data key and the second data key, and produce an output configuredto identify the first data record and the second data record in responseto identification of the match. In such embodiments, the apparatus 500may include an input adapter, a processor, and an output adapter.

The input adapter 502 may include an I/O adapter 310, a communicationsadapter 314, a user interface adapter 316, or the like. The processor504 may include the CPU 302 as described above with relation to FIG. 3.Alternatively, the processor 504 may include other hardware componentsincluding a firmware or software-based programmable logic chip, amicroprocessor, or the like. The output adapter 506 may include the I/Oadapter 310, the communication adapter 314, the display adapter 322, orthe like. For example, the output adapter 506 may store a map file tothe data storage 312 comprising a map or listing of matched datarecords. In one embodiment, the output may include the matched datarecords. In an alternative embodiment, the output may include metadataidentifying the matched data records.

FIG. 6 illustrates a further embodiment of an apparatus 600 for membermatching. The apparatus 600 may include a server 102 as described inFIG. 5. In a further embodiment, the processor 504 may include one ormore software defined modules configured to execute operations forgenerating a first data key from one or more field values in the firstdata record, comparing a second data key associated with a second datarecord with the first data key associated with the first data record,and identifying a match between the first data key and the second datakey. These modules may include a key generator 602, a comparison module604, and an identification module 606 respectively.

In a further embodiment, the key generator 602 may generate a pluralityof first data keys and second data keys according to a plurality ofpredetermined combinations of field values. Similarly, the comparisonmodule 604 may compare the first data key and the second data keyincludes comparing the plurality of first data keys with the pluralityof second data keys. For example, Table 1 includes several exampleembodiments of data keys that may be generated by the key generator 602.The “(v)” notation indicates that the field values may have been cleanedand/or standardized. The list in Table 1 is not intended to be anexhaustive list of possible keys that may be generated, but onlyindented to provide several examples for illustrative purposes only.

TABLE 1 Example data keys. Address + Zip + Sex + DOB(v) + FirstNm(v) +LastNm(v) Address + Zip + DOB + FirstNm(v) + LastNm(v) Address + Sex +DOB + FirstNm(v) + LastNm(v) Address + Zip + Sex + FirstNm(v) +LastNm(v) Address + DOB + FirstNm(v) + LastNm(v) Address + Zip +FirstNm(v) + LastNm(v) Address + Sex + FirstNm(v) + LastNm(v) Zip +Sex + DOB + FirstNm(v) + LastNm(v) Zip + DOB + FirstNm(v) + LastNm(v)Sex + DOB + FirstNm(v) + LastNm(v) + MiddleInit DOB + FirstNm(v) +LastNm(v) Phone + DOB + FirstInit + LastNm Phone + DOB + FirstNm +MiddleInit where Sex = ‘F’

In a further embodiment, the processor 504 may include additionalmodules. For example the processor 504 may include a data cleaner 608configured to clean the first data record and the second data recordbefore comparing the first data key and the second data key. Forexample, the data cleaner 608 may remove special characters such as ‘-’from names. The data cleaner 608 may also remove special characters suchas ‘/’, ‘-’, etc. from addresses. Additionally, the data cleaner 608 mayremove spaces in names and addresses. In still another embodiment, thedata cleaner 506 may convert all fields into upper case. The datacleaner 608 may also edit SSNs to ensure their validity. For example, anSSN like ‘111-11-1111’ may be identified as an invalid SSN. A leadingzero may be added to SSNs with only eight digits.

In one embodiment, the processor 504 may include a data standardizer 610configured to standardize the first and second data record beforecomparing the first data key and the second data key. In one embodiment,the standardizer 610 may perform a phonetic name matching algorithm. Forexample, the standardizer 610 may use the Soundex® algorithm availablewith Statistical Analysis Software (SAS). In such an embodiment, namessuch as “Bryan” and “Brian” may have the same encrypted value of “B65.”The standardizer 610 may also standardize first and last names, forexample the names “Jonathon,” “John,” and “Jon” may all be assigned to“Jon” to avoid confusion based on name variation. Street names may alsobe standardized. For example, “Avenue” may be assigned reassigned as“AVE.” First and last names may be swapped, for example to capturepeople with two first names, foreign names, or to correct for data entryerrors. In a further embodiment, the standardizer 610 may generate asubstring of the first 3 characters of each name to minimize errors inspelling. Table 2 illustrates several example embodiments of variationsthat may be generated through the data cleaning and standardizationprocesses described above.

TABLE 2 Exemplary variations of data cleaning and standardizationresults. VALUE VARIATIONS 23 Forest Ave 23 FOREST AVENUE 23 FOREST AVEHigh land HIGHLAND Bobby Smyth BOB SMITH BOB SMYTH ROBERT SMITH ROBERTSMYTH BOBBY SMITH BOBBY SMYTH 77 Ingle-Wood St 77 INGLEWOOD ST 77INGLEWOOD STREET

The schematic flow chart diagrams that follow are generally set forth aslogical flow chart diagrams. As such, the depicted order and labeledsteps are indicative of one embodiment of the presented method. Othersteps and methods may be conceived that are equivalent in function,logic, or effect to one or more steps, or portions thereof, of theillustrated method. Additionally, the format and symbols employed areprovided to explain the logical steps of the method and are understoodnot to limit the scope of the method. Although various arrow types andline types may be employed in the flow chart diagrams, they areunderstood not to limit the scope of the corresponding method. Indeed,some arrows or other connectors may be used to indicate only the logicalflow of the method. For instance, an arrow may indicate a waiting ormonitoring period of unspecified duration between enumerated steps ofthe depicted method. Additionally, the order in which a particularmethod occurs may or may not strictly adhere to the order of thecorresponding steps shown.

In still a further embodiment, the processor 504 may include an IDassignment module 612 configured to assign a common identifier to one ormore matching records that have been identified by the identificationmodule 606. Specifically, the ID assignment module 612 may assign acommon identifier to the first data record and the second data record inresponse to the match between the first key and the second key, thecommon identifier associating the first data record and the second datarecord with a unique entity. The common identifier may be unique to theentity. An entity may include an individual, a company, an organization,a plan, or the like. For example, the ID assignment module 612 mayassign a ID number, a unique user-name, an alpha-numeric identifier, abinary identifier, a hexadecimal identifier, or the like. The commonidentifier may include a social security number, a member identificationnumber associated with a member of a healthcare plan, or the like. In aparticular embodiment, each matched records associated with a particularindividual or member of a healthcare plan may be assigned the samemember ID by the ID assignment module 612. In such an embodiment,subsequent record matching searches may be simplified by matchingcertain records by member ID prior to the member matching processdescribed in FIG. 7.

FIG. 7 illustrates one embodiment of a method 700 for member matching.In one embodiment, the method 700 starts when the input adapter 502receives 702 a first data record from a plurality of data records storedin databases located on the data storage devices 202-206. The keygenerator 602 may then generate 704 a first data key from one or morefield values in the first data record. Example data keys that may begenerated 704 by the key generator 602 are shown above in Table 1.

The comparison module 604 may then compare 706 a second data keyassociated with a second data record with the first data key associatedwith the first data record. The identification module 606 may thenidentify 708 a match between the first data key and the second data key.In response to a match identified by the identification module 606, theoutput adapter 506 may produce 710 an output configured to identify datarecords associated with the match.

For example, Table 3 illustrates one embodiment of a group of datarecords associated with a hypothetical pair of individuals, Sally Jonesand John Smith. In this example, the individuals are divorced and haveone child named Bobby Smith. To further illustrate the presentembodiments, this example assumes that Sally used the name Sally Smithand was covered under John's health insurance plan during the time thatthey were married, but Sally changed her name to Sally Jones after thedivorce. This example further assumes that John and Sally are currentlycovered under separate health insurance plans and that Bobby is coveredby both plans. This example is not intended to limit the presentembodiments in any way, but to provide an illustrative example of howthe present apparatus, system, and methods may match health insurancerecords. This example would not require the use of social securitynumbers or other identification numbers for matching the records.

TABLE 3 Exemplary data records. Jan. 27, 2005 - Jul. 10, 2005 - PCPvisit ER visit Sally Smith Bob Smith DOB: 3/2/1957 DOB: 9/17/1989 Sex: FSex: M Address: 23 Forest Ave, Address: 23 Forest Ave, High land, MA,02127 Highland, MA, 02127 Phone: 781-223-2456 Phone: 617-888-8989 HealthPlan: BCBSMA Health Plan: BCBSMA Feb. 23, 2005 - Nov. 14, 2005 -Orthopedic visit Prescription refill Sally Smith Bobby Smyth DOB:3/2/1957 DOB: 9/17/1989 Sex: F Sex: M Address: 23 Forest Avenue,Address: 77 Inglewood St, Highland, MA, 02127 Bloomingdale, MA 02231Phone:781-223-2456 Phone: 781-223-2456 Health Plan: BCBSMA Health Plan:UHC May 18, 2005 - Lab test Sally Jones DOB: 3/2/1957 Sex: F Address: 77Ingle-wood St, Bloomingdale, MA 02231 Phone: 781-223-2456 Health Plan:UHC

In this example, the data records may be stored in two separatedatabases, each stored on a separate data storage device 202, 204. Insuch an embodiment, the input adapter 502 may receive 702 the first datarecord from the database stored on the first data storage device 202. Ina further embodiment, the data cleaner 608 may remove extraneousmarkings and spaces from the data fields and the data standardizer 610may generate a list, table, or file of standardized variations. The keygenerator 602 may then generate 704 a first data key from one or morefield values in the first data record. For example, the key generator602 may generate the “Address+Zip+Sex+DOB(v)+FirstNm(v)+LastNm(v)” keybased on values of data fields from the first data record. In thisexample, the “Address+Zip+Sex+DOB(v)+FirstNm(v)+LastNm(v)” key may be“23 FORESTAVENUE02127F03021957SALLYSMITH.”

The comparison module 604 may then compare 706 a second data keyassociated with the second data record with the first data keyassociated with the first data record. In such an embodiment, the seconddata key may be generated 704 in the same or similar manner as describedfor generating 704 the first data key. For example, the“Address+Zip+Sex+DOB(v)+FirstNm(v)+LastNm(v)” data key for the seconddata record may also be “23FORESTAVENUE02127F03021957SALLYSMITH.” Inthis example, the identification module 606 may identify 708 a matchbetween the first data key and the second data key.

The output adapter 506 may then produce 710 an output configured toidentify data records associated with the match. For example, the outputmay include a file containing the first data record and the second datarecord. Alternatively, the output may include a string of pointers, eachpointer configured to indicate a position on the first data storagedevice 202 and/or the second data storage device 204 at which the firstand second data records may be located. In a further alternativeembodiment, the output may include a list of database index values orother data record identifiers for locating the first data record and thesecond data record within one or more databases.

In the example described above, a“Address+Zip+Sex+DOB(v)+FirstNm(v)+LastNm(v)” data key associated withthe first data record and the third data record may not match. In suchan embodiment, the key generator 602 may generate 704 a plurality ofdata keys as described in Table 1. The comparison module 604 may thencompare 706 multiple data keys associated with the first data record andthe second data record. In this example, the identification module mayidentify a match based on the “Sex+DOB+FirstNm(v)+LastNm(v)” data keyand other possible data keys. Thus, the “Sex+DOB+FirstNm(v)+LastNm(v)”data key may account for changes of address.

FIG. 8 is a high-level schematic flowchart diagram illustrating oneembodiment of a method 800 for member matching. In particular, themethod 800 illustrates one embodiment of a method for receiving 802 datarecords from multiple data sources. In such an embodiment, the datarecords received from multiple data sources may be stored in aconsolidated data storage device 208. The method 800 may also receive804 data records from a “current” Xwalk dataset which include datarecords are associated with plan specific member IDs, wherein the planspecific member IDs are assigned corresponding common unique sequentialuniversal IDs (UID) by previous member matching processes or cycles.

The method 800 may further include calling a sub-process, sub-routine,web service, or the like for performing a member matching routine 806that matches members within and across the various data sources. Theroutine may be excused by an iterative process flow 900 started by X andillustrated in FIG. 9. The member matching routine may return 808 one ormore member matching reports and/or generate 810 an output configured toidentify matching data records. In the depicted embodiment, the outputmay be a file or data structure referred to herein as an “Xwalk.” TheXwalk may link data records that match a single individual. In thisembodiment, the member matching routine 806 may generate 810 a “New”Xwalk. In particular, the method 800 may achieve universal ID (UID)persistence across runs by updating Xwalk files or datasets to keeptrack of new members that are being added to the system as well asmembers that are dropped. For example, the method 800 may accept 812 theresults of the member match routine 806, as exemplified by renaming“Current” Xwalk in 804 from previous run to “Old” Xwalk and “New” Xwalkin 810 with new results to “Current” Xwalk. The method 800 may furthergenerate 814 updated “current” Xwalk by assigning UIDs to plan specificmember IDs. In the decision juncture 816 of resetting Xwalk, if theanswer is “Yes,” the method 800 may be followed by unacceptance of matchroutine by renaming “current” Xwalk to “New” Xwalk and “Old” Xwalk to“current” Xwalk as an optional step so as to generate 820 updated“current” Xwalk. If the answer is “No” for 816, the method 800 maycontinue by applying 822 “Current” Xwalk across the multiple datasources.

FIG. 9 is a schematic flowchart diagram illustrating one embodiment of asub-process 900 for preparing one or more data records, setting up thebinary tree flow for member matching the various data sources, executingsuch an order (1000, 1100), and generating the universal IDs to beassigned to plan specific member ID in XWalk and other reports. In thedepicted embodiment, the sub-process 900 may include creating 904 a mapof names and nicknames from Nicknames spreadsheet 902 and iterativelyupdated by steps 904-924. The nicknames may be stored in a spreadsheetof nicknames such as Nicknames spreadsheet 902 which may be maintainedmanually and may have all nicknames for a name linked to a commondenominator, and the map created in 904 may be stored as a nicknamelookup dataset 906. In this embodiment, the nickname lookup dataset iscalled “$nick lookup dataset.”

The sub-process 900 may further include obtaining 908 previously usedUIDs for healthplan specific member identification numbers from aprevious version(cycle) of the Xwalk dataset, for example from the“Current” Xwalk Dataset 910 to get last used UIDs. The sub-process 900may the continue with the Set Flow process 912. The data source list(Data contributions (DC)) may be separated into SSN and non-SSN lists.The Set Flow process 912 may include creating sequence patterns frommember prep process and intra-plan, and inter-plan matches, afterseparating the DCs into separate lists. In one embodiment, each of theselists may be organized into an ascending sequence based on size and thenset into sequence patterns using a binary tree approach for efficientmember matching. Other sequence patterns may be used, including adescending sequence, a temporal-based sequence, or the like. The SetFlow process 912 may also create a sequence pattern for a final match1038 between SSN match result 1020 and non-SSN match result 1032 asillustrated and described in FIG. 10.

The data source sequence patterns may then be passed to anothersub-process 1000 as illustrated in FIG. 10 for executing the variousbinary member prep processes and matches per the sequence patterns. Thesub-process 1000 may return a dataset comprising data records matched tomembers or individuals. A new Xwalk dataset may then be generated 920.In a further embodiment, one or more reports may be created 924.

In one embodiment, the “Current” XWalk 910 may be applied to the datafrom the health plans to identify members that have already been matchedat the beginning of each run. The “Current” Xwalk (XWalk as of previousrun) may be updated with the newly generated UID

MemberID entries from the current run's member matching processes(Execute Flow process 914) to create 916 the “New” Xwalk. For the nextrun, the “New” Xwalk may be converted into “Current” XWalk by the“Accept” process 812.

FIG. 10 is a schematic flowchart diagram illustrating one embodiment ofa sub-process 1000 for performing a preliminary match search based onsocial security numbers or member identifiers. In a specific embodiment,FIG. 10 may be an elaboration of the Execute_Flow process 914illustrated and described in FIG. 9. In one embodiment, the Execute_Flowprocess 914 may use the various sequence patterns provided to it by theSet_Flow process 912.

For example, patterns that may be provided to the Execute Flow process914 by the Set_Flow process 912 may include a sequence for Member_Prepfor plans with SSN. In such an embodiment, the Execute_Flow 914 maystart the Member_prep process per the sequence 1010 and provides SSNmember-match-ready datasets 1012. In one embodiment, a sequence forMember_Prep for plans without SSN may be generated. In such anembodiment, Execute_Flow may start the Member_prep process per thesequence 1022 and provides non-SSN member-match-ready datasets 1024. Inanother embodiment, a sequence for Member_Match for plans with SSN maybe generated. Execute Flow 914 may start 1018 multiple parallel (basedon dependencies) binary member matches in batch mode per the matchedsequence provided by Set_Flow 912. In a further embodiment, a sequencefor Member_Match for plans without SSN may be generated. In such anembodiment, the Execute Flow process 914 may start 1028 multipleparallel (based on dependencies) binary member matches in batch mode perthe matched sequence provided by Set_Flow 912.

In one embodiment, the sub-process 1000 may perform a preliminary searchfor data records that match according to a social security number and/ora member identification number. If the data records do not containsocial security numbers or other identification numbers, the membermatching sub-process 1100 (“Z” in FIG. 10) may be called. In oneembodiment, the member matching sub-process 1100 may return one or moredatasets comprising data records that have been matched to an individualor a member. In a further embodiment, the data resulting from SSN matchand non-SSN match are member matched to get the final member matcheddataset 1038.

FIGS. 11A-11B are schematic flowchart diagrams illustrating asub-process 1100 for member matching. In one embodiment, the sub-process1100 may include a data validation process 1102. The data validationprocess 1102 may include cleaning the data and/or standardizing the dataas described above. In a specific embodiment, data validation mayinclude applying social security number edits, converting all characterfields to upper-case, and standardizing addresses. The sub-process 1100may also include generating a plurality of data keys. In a specificembodiment, thirty nine to forty keys may be generated for each datarecord. The keys may include member-based keys, social securitynumber-based keys, and/or common keys (See Table 1).

For intra-plan match, if SSN is the DC (Data Contributor), thesub-process 1100 may generate 1108 member-based keys, SSN-based keys,and common keys for each data record; if SSN is not in the DC,member-based keys and common keys may be generated 1110. For inter-planmatch to compare data records from different data sources like differenthealth plans, the sub-process 1100 may generate only common keys when noSSNs are available and created SSN-based keys and common keys when SSNsare available. A particular advantage of the invention is that itsability to compare and match data records even when SSN, or planspecific subscriber numbers or member IDs are not available.

The keys generated by one or more processes 1108-1110 and 1114-1116 maybe combined 1118 into a key set. For example, a key set may includemultiple common keys and one social security number key, or onemember-based key such as member IDs or subscriber number specific forindividual plan or data contributor. For example, the key set mayinclude between thirty-five and forty separate common keys. In such anembodiment, the common key values may be concatenated variations of theindividual's demographic data fields. A key type such as a sequentialnumber may be assigned to each common key so that data common keys maybe identified and compared with other common keys of the same type. In afurther embodiment, the key type may increase the confidence of membermatchings. For example, without key_type, common key_values fordifferent members could be identified as the same member.

In a further embodiment, a lookup data set (DC#2) may be created 1120.The lookup dataset may include multiple records for each key typeassociated with each data record. The lookup dataset may be furtherconsolidated by identifying and removing duplicate records based on keytypes and key values. The dataset may then be indexed or sortedaccording to the key type and/or the key value.

The first data record may then be received 1122. In a particularembodiment, the input adapter 502 may receive the first data record inDC#1. The sub-process 1100 may additionally include dynamically creating1124 multiple data keys for the first data record in DC#1, according toa preselected set of key types associated with the key set associatedwith the lookup dataset (DC#2). Each data key generated for the firstdata set in DC#1 may be compared 1128 with the data keys in the lookupdataset (DC#2) created in 1120. If a match is found, the data recordsmay be 1132 flagged as matching or as a “HIT”, and an identificationnumber may be assigned to the matching data records. The matched recordwould have the demographic information from DC#2. In a furtherembodiment, the matched record may be 1134 assigned a universal ID(UID): if DC#1 and DC#2 already have a UID, choose the smaller UID; ifonly one of them has a UID, assign the UID to the matched record; if noDC has a previously UID, created a new one by obtaining the greatestunused UID. If no match is found, the first data record may be flaggedas a unique or unmatched data record. Specifically, the data record maybe flagged as associated with a new individual or member of a healthplan. This process may be repeated iteratively until each data key foreach data record has been looked up in the lookup dataset.

Once all of the data records have been looked up, demographicinformation may be captured 1146 for the matched records from both datasources. This may include extracting the demographic information foreach matched data record and storing it as a separate matched record.The demographic information may facilitate future match searches, makingthe sub-process 1100 more accurate. The unmatched records may be 1148assigned unique identification numbers, and flagged as unmatchedrecords. This information may be compiled 1150 into a final match resultdataset 1152, and returned to the sub-process 1000.

In further embodiments, the apparatus, system and methods describedherein may handle matching between three or more datasets associatedwith three or more distinct plans. In an alternative embodiment, abinary tree matching method may be used to match data records from twoseparate plans at substantially the same time. These methods may beflexible enough to allow varying identifier fields between datasets,since all datasets may not have common identifier fields. For example, amapping or association of identifier fields may be generated prior toexecution of the methods. In still further embodiments, a set of logicalrules for match corroboration or disqualification may be implemented tovalidate matches. Weighting may also be provided to identify closematches or to provide a level of confidence in the matches. For example,matches based on complex data keys may be assigned a high weightingvalue, indicating a high level of confidence in the match, while matchesbased on simple data keys may be assigned a low weighting value,indicating a low level of confidence in the match. This information maybe communicated to a user.

The described embodiments may have several advantages. First, thedescribed embodiments are able to match members without the use ofsocial security numbers or plan specific Subscriber Number or Member ID.Second, multiple matching keys in sequence, testing multiplecombinations of demographic fields may be used to captures members whomove from one location to another, who get married or divorced andchange names, who have dual coverage even if demographic information isnot identical in both plans, who have data records within one datasource and also across data sources. This methodology can haveapplications in various fields where individuals need to be matched andidentified across various similar data sources.

All of the methods disclosed and claimed herein can be made and executedwithout undue experimentation in light of the present disclosure. Whilethe apparatus and methods of this invention have been described in termsof preferred embodiments, it will be apparent to those of skill in theart that variations may be applied to the methods and in the steps or inthe sequence of steps of the method described herein without departingfrom the concept, spirit and scope of the invention. In addition,modifications may be made to the disclosed apparatus and components maybe eliminated or substituted for the components described herein wherethe same or similar results would be achieved. All such similarsubstitutes and modifications apparent to those skilled in the art aredeemed to be within the spirit, scope, and concept of the invention asdefined by the appended claims.

1. An apparatus comprising: an input adapter configured to receive afirst health care data record from a first health care plan and a secondhealth care data record from a second health care plan from a pluralityof health care data records stored in one or more databases, where eachof the first and second health care data records comprises a pluralityof field values; a processor coupled to the input adapter, the processorconfigured to: generate a plurality of first data keys, where each firstdata key corresponds to a predetermined combination of at least twofield values in the first health care data record; generate a pluralityof second data keys, where each second data key corresponds to apredetermined combination of at least two field values in the secondhealth care data record; compare the plurality of second data keys tothe plurality of first data keys; assign a first identifier to the firstand second health care data records, if a match between the plurality offirst data keys and the plurality of second data keys is identified; andassign a second identifier to the first and second health care datarecords, if no match between the plurality of first data keys and theplurality of second data keys is identified; and an output adaptercoupled to the processor, the output adapter configured to produce anoutput in response to the comparison result.
 2. The apparatus of claim1, where the processor is further configured to clean the first healthcare data record and the second health care data record before comparingthe first data key and the second data key.
 3. The apparatus of claim 1,where the processor is further configured to standardize the first andsecond health care data records before comparing the first data key andthe second data key.
 4. The apparatus of claim 3, wherein standardizingthe first and second health care data records comprises assigning a sameencrypted value to a plurality of variables which represent a same fieldvalue.
 5. The apparatus of claim 1, where comparing the plurality offirst data keys and the plurality of second data keys further comprises:sequentially comparing each first data key to a second data key; andterminating the comparison once a match is identified.
 6. The apparatusof claim 1, where the first identifier comprises a common identifierassociating the first health care data record and the second health caredata record with a unique entity.
 7. A system comprising: one or moredata storage devices configured to store a plurality of health care datarecords from one or more health care plans; and a server in datacommunication with the data storage device, the server configured to:receive a first health care data record from a first health care planand a second health care data record from a second health care plan fromthe plurality of health care data records stored in one or moredatabases located on the one or more data storage devices, where each ofthe first and second health care data records comprises a plurality offield values; generate a plurality of first data keys, where each firstdata key corresponds to a predetermined combination of at least twofield values in the first data record; generate a plurality of seconddata keys, where each second data key corresponds to a predeterminedcombination of at least two field values in the second health care datarecord; compare the plurality of second data keys with the plurality offirst data keys; assign a first identifier to the first health care datarecord and second health care data record, if a match between theplurality of first data keys and the plurality of second data keys isidentified; assign a second identifier to the first and second healthcare data records, if no match between the plurality of first data keysand the plurality of second data keys is identified; and produce anoutput in response to the comparison result.
 8. The system of claim 7,where the server is further configured to clean the first health caredata record and the second health care data record before comparing thefirst data key and the second data key.
 9. The system of claim 7, wherethe server is further configured to standardize the first and secondhealth care data records before comparing the first data key and thesecond data key.
 10. The system of claim 9, wherein standardizing thefirst and second health care data records comprises assigning a sameencrypted value to a plurality of variables which represent a same fieldvalue.
 11. The system of claim 7, where comparing the plurality of firstdata keys and the plurality of second data keys further comprisessequentially comparing each first data key to a second data key; andterminating the comparison once a match is identified.
 12. The system ofclaim 7, where the first identifier comprises a common identifierassociating the first health care data record and the second health caredata record with a unique entity.
 13. A tangible computer programproduct comprising a non-transitory computer readable storage mediumhaving computer usable program code executable to perform operationscomprising: receiving a first health care data record from a firsthealth care plan and a second health care data record from a secondhealth care plan from a plurality of health care data records stored inone or more databases, where each of the first and second health caredata records comprises a plurality of field values; generating aplurality of first data keys, where each first data key corresponds to apredetermined combination of at least two field values in the first datarecord; generating a plurality of second data keys, where each seconddata key corresponds to a predetermined combination of at least twofield values in the second health care data record; comparing theplurality of second data keys with the plurality of first data keys;assigning a first identifier to the first and second health care datarecords, if a match between the first plurality of data keys and theplurality of second data keys is identified; assigning a secondidentifier to the first and second health care data records, if no matchbetween the plurality of first data keys and the plurality of seconddata keys is identified; and producing an output in response to thecomparison result.
 14. The tangible computer program product of claim13, the operations comprising cleaning the first health care data recordand the second health care data record before comparing the first datakey and the second data key.
 15. The tangible computer program productof claim 13, the operations comprising standardizing the first andsecond health care data records before comparing the first data key andthe second data key.
 16. The tangible computer program product of claim15, wherein standardizing the first and second health care data recordscomprises assigning a same encrypted value to a plurality of variableswhich represent a same field value.
 17. The tangible computer programproduct of claim 13, where the operation for comparing the plurality offirst data keys and the plurality of second data keys further comprisessequentially comparing each first data key to a second data key; andterminating the comparison once a match is identified.
 18. The tangiblecomputer program product of claim 13, the first identifier comprising acommon identifier associating the first health care data record and thesecond health care data record with a unique entity.
 19. A methodcomprising: receiving a first health care data record from a firsthealth care plan and a second health care data record from a secondhealth care plan from a plurality of health care data records stored inone or more databases, where each of the first and second health caredata records comprises a plurality of field values; generating aplurality of first data keys, where each first data key corresponds to apredetermined combination of at least two field values in the firsthealth care data record; generating a plurality of second data keys,where each second data key corresponds to a predetermined combination ofat least two field values in the second health care data record;comparing the plurality of second data keys with the plurality of firstdata keys; identifying a match between the plurality of first data keysand the plurality of second data keys; and assigning a first identifierto the first health care data record and to the second health care datarecord, if a match between the first plurality of data keys and theplurality of second data keys is identified; assigning a secondidentifier to the first health care data record and to the second healthcare data record, if no match between the plurality of first data keysand the plurality of second data keys is identified; and producing anoutput in response to the comparison result.
 20. The method of claim 19,comprising cleaning the first health care data record and the secondhealth care data record before comparing the first data key and thesecond data key.
 21. The method of claim 19, comprising standardizingthe first and second health care data records before comparing the firstdata key and the second data key.
 22. The method of claim 21, whereinstandardizing the first and second health care data records comprisesassigning a same encrypted value to a plurality of variables whichrepresent a same field value.
 23. The method of claim 19, wherecomparing the plurality of first data keys and the plurality of seconddata keys further comprises sequentially comparing each first data keyto a second data key; and terminating the comparison once a match isidentified.
 24. The method of claim 19, the first identifier comprisinga common identifier associating the first health care data record andthe second health care data record with a unique entity.